REMARKS /ARGUMENTS 



The Office Action dated November 1, 2007 has been 
received and carefully studied. In addition, the applicant 
wishes to thank the Examiner for his time during the 
telephonic interview of January 18, 2007. 

The Examiner rejects claims 1-8, and 20-25 under 35 
U.S.C. §102 (e) as being anticipated by Ikonen (U.S. Patent 
No. 7, 003, 575). With respect to claims 1, 3, 24, and 25, 
the Examiner states that Ikonen teaches a method and a 
respective computer program for operating a computer 
network server in a computer network comprising maintaining 
a connection with a central node, receiving a command from 
said central node to open a listening port after central 
node receives a request from a client to access said 
server, opening a listening port, sending to the central 
node instructions for the client to connect to the server 
over the listening port and receiving communication from 
the client after the central node delivers a command to the 
client to connect to the server. 

This rejection is respectfully traversed. First, with 
respect to claims 1 and 24, those claims require that the 
server access the central node, obtain network addresses 
for the intended clients, and establish a connection to 
those clients. The Examiner does not recite these steps in 
the Office Action, rather only the steps associated with 
claims 3 and 25 are discussed. Furthermore, this method of 
communication between the server and the client is not 
discussed in the Ikonen reference. Specifically, Ikonen 
does not disclose that the server establishes a connection 
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to specific clients. Rather, Ikonen discloses that the 
client always initiates communication with the server. In 
response to this argument, the Examiner states that the 
language used in the claim '"establishing" is broad and does 
not indicated which party is the initiator. Although the 
applicant disagrees with this assertion, to expedite 
allowance, claims 1 and 24 have been amended to clearly 
recite that it is the server that initiates the connection 
with the clients. Thus, in view of this amendment, claims 
1 and 24, and all claim's dependent on those claims are 
believed to be in condition for allowance. 

With respect to claim 3, the Examiner states that 
Ikonen discusses all of the recited steps and cites 
specific passages in columns 8 and 9 for support. This 
rejection is respectfully traversed. In response to the 
last office action and the subsequent telephonic interview, 
the Examiner stated that the rejection assumes that the 
redirection database 703 corresponds to the server in the 
present claim, and the server 702 of Ikonen corresponds to 
the central node in the present claim. Even assuming this 
configuration, Ikonen does not anticipate the present 
claim. Referring to Figure 7, the communication mechanism 
is quite different. Client 701 connects to server 702. 
Server 702 requests a service address from redirection 
database 703. The redirection database 703 responds to the 
server 702, and either deasserts the redirection flag (see 
Figure 7) or asserts the redirection flag (see Figure 8) . 
If the redirection flag is not asserted, communication 
between client 701 and server 702 is continued. If the 
redirection flag is asserted (as shown in Figure 8), the 
server 802 directs the client 801 to a different server 
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having the requisite service address. The client 801 then 
connects to that second server 804. 

This communication is markedly different that that 
recited in claims 3 and 25. For example, the fourth recited 
step requires ""sending to said central node instructions 
for said client to connect to said server over said 
listening port". However, in Ikonen, no communication is 
ever conducted between the client 701 and the redirection 
database 703 (which the examiner considers to be the 
server) and no connection is ever made or attempted. The 
communication between the redirection database 701 and the 
server 702 is simply to tell the server whether it should 
communicate with the client, or direct the client to a 
different server 804. No communication is ever suggested or 
disclosed between the client and the redirection database. 
Thus, the fourth step of claim 3 is not anticipated by 
Ikonen. 

In addition, the final step requires the server to 
receive ''communication from said client over said listening 
port after said central mode delivers a command to said at 
least one client to connect to said server". Again, the 
Examiner assumes that the redirection database 703 
corresponds to the server in the claim, and that the server 
702 corresponds to the central node. Using this 
configuration, Ikonen does not disclose that the 
redirection database 703 received communication from the 
client after the server 702 delivers a command to the 
client to connect to the redirection database. The server 
702 instructs the client whether it should communicate with 
the server 702 or a different server 804. There is no 



11 



suggestion that the client ever communicates with the 
redirection database 703. The line labeled 807 in Figure 8 
of Ikonen simply shows the client connecting to server 804; 
there is no communication to or through the redirection 
database suggested or disclosed. Thus, the fifth step of 
the method recited in claim 3 is also not anticipated by 
Ikonen. 

Furthermore, Ikonen discloses a method for solving a 
completely different problem than the present invention. 
Ikonen is concerned with sharing the load between a number 
of accessible servers. It accomplishes this by having a 
redirection database which determines whether a client, 
after making initial contact with a server, should be 
allowed to continue communicating with that server, or 
whether another server is a more appropriate target of the 
client's communications. In fact, claim 1 of Ikonen recites 
that method of communication begins with a packet sent from 
the client to a first server. This method of communication 
allows communication between a client and one or more 
servers. In stark contrast, the present invention attempts 
to minimize access to the server, unless properly 
authorized by a central node. Thus, while the client 
initiates contact with the server in Ikonen as the first 
step of the process, such a client-server contact is the 
final step of the communication process in the present 
invention. All communications before that point are between 
the central node and the server or the central node and the 
client. However, in Ikonen, the client always communicates 
with servers, and never with the redirection database. 
Thus, claim 3 and all claims dependent on that claim are 
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not anticipated by Ikonen and are believed to be in 
condition for allowance. 

The Examiner also rejects claim 25 for this same 
reasons listed above. Since claim 25 recites a computer 
program having the means to implement the steps recited in 
claim 3, it is not anticipated by Ikonen for the reasons 
stated above. 

The Examiner rejects claim 2, noting the Ikonen 
discloses a Network Translation device. Claim 2 is 
dependent on claim 1. By virtue of the accompanying 
amendment, claim 1 is believed to be in condition for 
allowance. Thus, claim 2 by virtue of its dependence on 
claim 1 is believed to be allowable. 

The Examiner rejects claim 4, stating that Ikonen 
discloses a predetermined listening time of less than one 
second. This rejection is respectfully traversed. Ikonen 
never discusses or discloses any information concerning the 
accessibility of the listening port, and clearly never 
discloses this time as being less than one second. 
Furthermore, this claim is allowable due to its dependence 
on claim 3, as described above. 

The Examiner rejects claim 5, stating that Ikonen 
discloses closing the listening port after receipt of a 
communication, noting that closing the port is inherent. 
This rejection is respectfully traversed. There is no 
disclosure that the server closes the listening port after 
receipt of the message. In fact, it is obvious that the 
listening port remains accessible since other clients can 
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and are allowed to access the server. Furthermore, this 
claim is allowable due to its dependence on claim 3, as 
described above. 

The Examiner rejects claim 6, stating that Ikonen 

discloses establishing a network connection after receipt 

of a communication. This claim is allowable due to its 
dependence on claim 3, as described above. 

The Examiner rejects claim 7, stating that Ikonen 
discloses that the server closes its listening port if it 
receives communication from other than the authorized 
client, citing column 10, lines 1-30. Ikonen, neither in 
the cited passage nor anywhere in the specification, 
discloses that the server will close its listening port if 
accessed by an unauthorized client. In fact, as mentioned 
above, the server is generally available for communication 
from all clients, and thus such an action would not be 
beneficial for a load sharing application. Furthermore, 
this claim is allowable due to its dependence on claim 3, 
as described above. 

The Examiner rejects claim 8, stating that Ikonen 
discloses a persistent connection with the central node. 
This claim is allowable due to its dependence on claim 3, 
as described above. 

The Examiner rejects claim 20, stating that Ikonen 
discloses a computer system, comprising a central node, a 
server and at least one authorized client, wherein said 
server is adapted to receive notification from said central 
node that said authorized client wishes to communicate with 
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said server and in response to said notification^ is 
adapted to open a listening port for said authorized client 
to connect to and sends instructions to said central node 
to notify said authorized client to communicate to said 
listening port. The Examiner cites the passages listed 
above and Figures 7 and 8 for support. 

It is unclear from the Office Action how the Examiner 
interprets Ikonen to make this rejection. Ikonen describes 
two scenarios for load sharing, shown in Figures 7 and 8. 
If the Examiner is applying the scenario described in 
Figure 1, the rejection is improper. Claim 20 requires that 
the server opens a listening port after being notified by 
the central node and then sends instructions to the central 
node to notify the client. In Figure 1, it is clear that 
the client communicates directly with the server before the 
central node ever notifies the server of the client's 
intention. Furthermore, the server never sends instructions 
to the central node to notify the client to communicate on 
the listening port (since communication is already 
occurring) . Even if the Examiner is treating the 
redirection database 703 as the server and the server 702 
as the central node, the rejection is still improper. Using 
this interpretation, the client of Ikonen never ''wishes to 
communicate" with the redirection database as recited in 
claim 20. The only communications to the redirection 
database 703 are from the server 702 verifying the proper 
server with which the client should communicate. 

If the Examiner is applying the scenario shown in 
Figure 8, and treating server 1 as the ''server" as recited 
in the present claim, the rejection is improper. Server 1 
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conimunicates with the client before any notification by the 
server. In fact, the notification that is received informs 
the server 1 to terminate, not initiate, communications 
with the client. Again, the server never sends instructions 
to the central node to notify the client to communicate on 
the listening port. Lastly, if the Examiner is applying the 
scenario shown in Figure 8, and treating server 2 as the 
''server" as recited in the present claim, the rejection is 
still improper. In figure 8, server 2 is never notified by 
the central node of the client's desire to communicate. 
Rather, the only communication to which server 2 is a 
participant is between the client and server 2. Server 2 
has no interaction at all with the central node. Finally, 
if the Examiner is treating the redirection database 803 as 
the server, the rejection is still improper, as the client 
never communicates with the redirection database as recited 
in the claim. Thus, claim 20 and all claims dependent on 
claim 20 are believed to be in condition for allowance. 

The Examiner rejects claim 21, stating that the server 
is adapted to close the listening port if an unauthorized 
client attempts to communicate. As explained above, this is 
not disclosed in Ikonen, and would not be beneficial to a 
load sharing application where multiple clients are in 
communication with multiple servers. Furthermore, this 
claim is allowable due to its dependence on claim 20, as 
described above. 

The Examiner rejects claim 22, stating that Ikonen 
discloses establishing a network connection after receipt 
of a communication. This claim is allowable due to its 
dependence on claim 20, as described above. 
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The Examiner rejects claim 23, stating that Ikonen 
discloses closing the listening port after receipt of a 
communication, noting that closing the port is inherent. 
This rejection is respectfully traversed. There is no 
disclosure that the server closes the listening port after 
receipt of the message. In fact, it is obvious that the 
listening port remains accessible since other clients can 
and are allowed to access the server. Furthermore, this 
claim is allowable due to its dependence on claim 20, as 
described above. 

The Examiner rejects claims 9-11 as being unpatentable 
under 35 U.S.C. §103 (a) over Ikonen. The Examiner takes 
official notice that encrypting communication packets is 
old and well known in the art for establishing secure 
communications. However, these claims are allowable due to 
their dependence on claim 3, which is believed to be in 
condition for allowance, based on the earlier arguments. 

Reconsideration and allowance are requested in view of 
the foregoing arguments. 
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